WIP: add rules-keeper #78
Conversation
|
@kormide PTL |
| // releases made at this version. | ||
| repeated Release releases = 6; |
There was a problem hiding this comment.
When would a ruleset version have more than one release?
There was a problem hiding this comment.
Ha, I thought Github allowed that.
|
We should make a new repository on the SIG account so we can start getting this in in smaller chunks. @alexeagle Do we need to have a vote with the SIG members before we create one? |
|
nit: I might name the |
|
I'm not super familiar with protobuf. For the rules_ts data you pulled, are the csv and METADATA files a serialization of the protobuf data? I always thought that protobuf was transferred (and stored) in some kind of binary format? |
| update_time: { | ||
| seconds: 1677692269 | ||
| nanos: 122313000 | ||
| } |
There was a problem hiding this comment.
For these METADATA files, is the update_time the time that the data was pulled? Is it necessary to store at the resolution of nanoseconds?
There was a problem hiding this comment.
Not necessary, but it comes directly from google.golang.org/protobuf/types/known/timestamppb. So I'd rather leave it as it is, instead of writing more code to truncate it.
|
Overall it's looking good so far. It might be good to start incrementally building out the interface as you build the schema to verify that we have all the information we'll need. |
I figured that the CSV is a compact way of storing time series, which is simple and git-friendly (packfiles). In the meanwhile, we can plot them with existing tools, say gnuplot. Which will make our next step easier. The METADATA is the corresponding metadata to the CSV file, which is defined in protobuf. The sole reason for using protobuf is to make marshal/unmarshal easier. Protobuf's wire format is binary, but it also has a text format, which is human-readable and git-friendly. It's totally possible to store the time series in proto as well, but we will end up with bloated text files. That's why I ended up with a combination of two. |
It's kind of a custom to put proto files in a proto directory. It's an implementation detail for sure, but this directory name will leak into import paths and package names, say Once I introduce rules_go to the repo, I'll remove the generated code. It will make the |
| string description = 4; | ||
|
|
||
| // prerelease marks if the release is a preprelease. | ||
| bool preprelease = 5; |
There was a problem hiding this comment.
| bool preprelease = 5; | |
| bool prerelease = 5; |
DO NOT SUBMIT
This CL implements rule-keeper, a GitHub App, to make rule authors' workflow smoother.
For now, it will only collect the data and present them on the ruleset catalog.
As of this CL:
To try this out:
With Github App:
go run . -app_id=TODO -private_key=TODOWith Personal Access Token:
go run . -personal_token=$TOKEN -owner=$OWNER -repo=$REPOUpdates #53